CyberArk Identity Management

Securely manage device credentials and SSH keys in a centralized vault.

To configure the system, you'll need the:

  • URL to CyberArk

  • Client Certificate

  • Client Certificate Password

If your CyberArk instance is hosted, then CyberArk is responsible for providing the host name, app ID, and safe.

To configure devices, you'll need to:

To learn more about configuring your CyberArk instance to communicate with SIP, please refer to CyberArk documentation.

Notes

  • Currently, we only test that the connection is correct when we reach out to retrieve credentials in CyberArk for a device (during device setup or retrieval). During device setup, we always test that the CyberArk account exists

  • The URL for CyberArk is typically <https://<Client> CyberArk DNS Name>/AIMWebService/api/Accounts?AppID=<CyberArk application id>&Query=safe=<Client safe_name>;Object=

  • Credentials not prefixed with the CyberArk keyword (default is cyberark://) will be treated as the actual credential and Security Manager will not call CyberArk to get the value.

  • Cache—currently, CyberArk instance caches credentials up to 25 minutes. This means retrievals from a device that has a password change will not work for up to 25 minutes. Each client instance that is on-prem will similarly affect retrieval.

  • Accounts—Each credential is stored as an "Account" in CyberArk. Although passwords can be stored with user names, we cannot point directly to the credentials and ask it to retrieve the user name and password. This means that each credential (user name, password, SSH key) needs to be stored independently in CyberArk, and configured in SIP.

  • Safe—Each credential belongs to a "safe" (think of a folder or category). Currently, we only support a single safe, since the entire Security Manager domain is tied to a single safe. We can use different safes provided they are associated with different domains and the devices whose credentials are in different safes are in different domains.